The present invention relates generally to methods of computing using remote calls between a local and a remote computer platform, and specifically to methods for preventing deadlock during such remote calls.
Multitasking using a plurality of threads within a program is well known in the art. Multithread programming is described, for example, in xe2x80x9cThe Java Language Environment: A White Paper,xe2x80x9d by James Gosling and Henry McGilton, published by Sun Microsystems, Inc., which is incorporated herein by reference. Use of more than one thread in a program allows multiple sequences of steps or states to be carried out by the program in parallel, by attaching a thread to each of the sequences. In the present patent application, the term thread refers to a sequence of steps carried out by the program. A thread has a thread identity as well as a priority.
In xe2x80x9cHooked on Java,xe2x80x9d by van Hoff et al., published by Addison-Wesley Publishing Company, which is incorporated herein by reference, the authors explain in Chapter 5 that deadlock occurs when two or more threads are unable to continue because they are waiting on each other indefinitely. The authors outline some strategies for avoiding deadlock in threaded programs, including, where possible, avoiding creating more than one thread to execute methods. The authors further suggest trying to hold locks (explained in more detail below) created by threads for the shortest time possible.
When a thread obtains a lock for an object for the first time, an identity of the locking thread is recorded in the lock. On subsequent attempts by the thread to lock the same object, the system validates that this thread is the one recorded as xe2x80x9cowningxe2x80x9d the lock, and if so, allows the thread to proceed. Other threads attempting to use the locked object are locked out, and must wait until the original thread releases the lock. A deadlock occurs if a thread T1 holds a lock L1 and requests a lock L2, while a thread T2 holds lock L2 and requests lock L1. Deadlock of multiple threads on a single machine can generally be avoided by careful programming.
In modern network environments, a program (or program thread) running on a local computing machine will frequently invoke operation of a program on another, remote machine via a network, and will then receive the results back from the remote machine. Such invocation is referred to as a remote call. Depending on the nature program invoked, the remote machine may also respond with a callback to the local machine, i.e., with a remote call of its own. Remote Method Invocation (RMI) enables a programmer to create an object whose methods can be invoked on a remote computer. In xe2x80x9cUsing Javaxe2x80x9d by Joseph Weber, et al., published by Que Corporation, which is incorporated herein by reference, the authors describe in Chapter 40 steps involved in implementing a remote object for use in RMI. However, using RMI, or any other remote procedure call known in the art, breaks local-remote transparency and can lead to deadlocks, as described below.
Threaded programs running on a local and on a remote machine need to make remote calls between the machines. In so doing, each remote call leads to creation of a new thread on a respective target machine (either the local or the remote machine) . In the event that the target machine then makes a callback to the local machine, the original thread identity and/or priority is not preserved.
FIG. 1 is a schematic diagram illustrating a generation of deadlock caused by this process, as is known in the art. A thread T1, running on a source machine 10, locks an object 16 and makes a remote call to a target machine 12, thereby invoking a method 14. The invoked method executes in a thread T2 running on target machine 12. During execution of this method, thread T2 makes a remote callback to source machine 10, which creates a new thread T3 on machine 10. If thread T3 tries to perform a lock on object 16, it will be unable to do so, and a deadlock will occur. Execution of a similar process in a single machine (without remote calls) will not cause any deadlocks, since for a single machine all locks are executed by the same thread. Thus, although it would be desirable for remote calls using RMI to be xe2x80x9ctransparentxe2x80x9d to the programmer, i.e., to require no special attention to the fact that the desired method is invoked on a remote, rather than local, processor, in actuality the programmer must take particular care to avoid such deadlocks.
It is an object of some aspects of the present invention to provide methods for the preservation of local-remote transparency within a computer programming environment.
It is a further object of some aspects of the present invention to provide methods to prevent deadlock within a computer program operating on a local and a remote platform.
It is a yet further object of some aspects of the present invention to provide methods to preserve a thread identity within a computer program operating on a local and a remote platform.
In preferred embodiments of the present invention, when a first program thread running on a source machine makes a remote call to a target machine, the remote call includes an identification of the thread. When the target machine receives the remote call, it generates a second thread to carry out whatever method or methods are required by the call, and associates the identification with the second thread. If the target machine must then make a callback to the source machine, the identification is further associated with the callback. When the source machine receives the callback, it is able, using the identification associated therewith, to determine the identity of the first thread and, thus, to perform any method required by the callback using the first thread. As a result, the thread is allowed access to any objects that had previously been locked by the first thread on the source machine, and the possibility of deadlock due to the callback is avoided. It will be appreciated that any number of successive mutual callbacks between source and remote machines may be handled in this fashion.
In some preferred embodiments of the present invention, a remote transmission system on a source machine comprises a method relay manager (MRM) object and a thread supply object, which generates a thread responsive to a command from the MRM object. A target machine has a similar remote transmission system, comprising an MRM object and a thread supply object substantially similar to those on the source machine. All remote calls and corresponding callbacks between the machines are transmitted and received via the respective MRM objects, which use their respective thread supply objects to preserve an identity of a thread associated with a remote call from one of the machines to the other and then returned to the original machine.
By utilizing substantially similar systems in both the source and target machines, local-remote transparency is maintained, while the possibility of deadlocks occurring is eliminated by preserving the identity of the thread during the performance of remote calls and associated callbacks.
In some preferred embodiments of the present invention, the identity of the thread associated with the call and callbacks is preserved using one or more intermediate threads generated on one or both machines during a transmission of the call. The identities of the intermediate threads are modified, responsive to instructions from either the source or the target machine, so as to maintain consistency with thread naming conventions, such as conventions associated with Java language programming.
In some preferred embodiments of the present invention, an identity of a lock is used to record an owner of the lock associated with the thread when the remote call is made. The identity of the lock is transferred with the remote call, and the lock identity, rather than the identity of the thread, is used in initially locking objects and in order to gain access to already locked objects, thus avoiding deadlock situations.
Preferred embodiments of the present invention are particularly useful when making remote calls using a synchronized method, as is commonly employed in Java language programming. For example, the present invention may be implemented using Java Remote Method Invocation (RMI), as described hereinabove, with the thread identification The principles of the present invention may be employed in substantially any processing environment that uses remote procedure calls.
There is therefore provided, in accordance with a preferred embodiment of the present invention, a method for performing remote calls between source and target computing machines, including:
running a program thread on the source machine which invokes a remote call to the target machine;
transmitting the remote call to the target machine, the call including an identifier associated with the program thread; and
receiving a response to the remote call from the target machine, the response including the identifier, whereby the response is returned to the program thread on the source machine using the identifier.
Preferably, transmitting the remote call includes generating at least one intermediate thread for routing the identifier.
Preferably, generating the at least one intermediate thread includes generating a thread to perform the remote call on the target machine, which thread generates a callback to the invoking thread on the source machine.
Alternatively, generating the at least one intermediate thread includes generating threads on the source and target machines, wherein the threads on the source and target machines are generated by substantially similar methods running on the source and target machines.
Preferably, transmitting the remote call includes incorporating an identity of the program thread and context parameters of the program thread in the identifier.
Alternatively, incorporating the identity of the program thread in the identifier includes generating an intermediate thread on the target machine whose thread name incorporates the identity.
Further alternatively, incorporating the identity of the program thread in the identifier includes altering the identifier responsive to information comprised in the remote call.
Preferably, incorporating the identity of the program thread in the identifier includes altering the identifier responsive to information comprised in the response to the remote call.
Preferably, running the program thread includes transmitting the remote call and receiving the response in a manner substantially transparent to a programmer using the method.
Alternatively, running the program thread includes utilizing the identifier so as to gain access to an object locked by the invoking thread, whereby a deadlock does not occur.
Preferably, transmitting the remote call includes incorporating an identity of a lock generated by the program thread in the identifier.
Preferably, the source machine and the target machine include Java Virtual Machines.
Alternatively, transmitting the remote call includes performing Remote Method Invocation in a program running in Java.
Preferably, transmitting the remote call includes placing a TCP/IP call.
There is further provided, in accordance with a preferred embodiment of the present invention, a computing machine, which runs a program thread that invokes a remote call to a target machine, the computing machine including a method relay manager, which transmits the remote call to the target machine, including an identifier associated with the program thread, such that a response to the remote call is received from the target machine, wherein the response including the identifier, so that the method relay manager returns the response to the invoking program thread using the identifier.
Preferably, the method relay manager generates at least one intermediate thread, which routes the remote call.
Preferably, the target machine includes a second method relay manager, which receives the remote call from the computing machine and which generates the response from the target machine responsive to the remote call.
Preferably, the method relay managers are substantially similar.
Alternatively, the computing machine includes a first thread supply object, and the target machine includes a second thread supply object, which objects respectively supply intermediate threads which route the remote call responsive to a request from their respective method relay managers.
Preferably, the thread supply objects are substantially similar.
Alternatively, the method relay manager includes a remote transmission method followed by the manager responsive to the remote call and to the response to the remote call.
Further alternatively, the method relay manager transmits the remote call and receives the response to the remote call in a manner substantially transparent to a programmer using the machine.
Preferably, the method relay manager carries out a Java remote method invocation process.
Alternatively, the remote invocation process incorporates an identity of a lock generated by the program thread in the identifier.
There is further provided, in accordance with a preferred embodiment of the present invention, a computer program product having computer-readable program code stored therein, responsive to which code a source machine runs a program thread which invokes a remote call to a target machine and transmits the remote call to the target machine, the call including an identifier associated with the program thread, wherein upon receiving a response to the remote call from the target machine, the response including the identifier, the source machine returns the response to the invoking program thread using the identifier.
The present invention will be more fully understood from the following detailed description of the preferred embodiments thereof, taken together with the drawings in which: